Many applications maintain data structures modelling the current state of a system, e.g. power stations, steel mills, telecoms systems. These data structures represent an abstraction of the real state of the system, where the level of abstraction is chosen to be sufficient for the intended purpose, e.g. management, fault tracking, billing. For small/simple systems it may be possible to store all this state in the memory of a computer. However, for larger systems, or where there are multiple applications, perhaps on different computers, or where a large degree of fault tolerance is required, this state needs to be stored in a database.
Writing the code to get data into and out of this database is not hard, but it is time-consuming, error-prone, can frequently obscure the more important aspects of the application logic and makes it hard to adapt rapidly to changes to our model of the system state.
A managed telecommunications network, for example a computer network, such as the Internet, typically comprises managed devices, such as: routers; switches; hubs; printers; and host computers; as well as at least one network management system (NMS). The managed devices are coupled by communications links.
For large networks, an NMS needs to store a large amount of state information in order to react to, correlate and manipulate the properties of the networks, or systems, under their control. This state information includes the current topology of the managed devices as well as the communication links between them. Each of these devices may itself have a considerable amount of state information associated with it. Some of this state information, such as the current set of Multi-Protocol Label Switching (MPLS) Label Switch Paths (LSPs), induces further levels of complex hierarchical state information. Clearly not all aspects of every device needs to be tracked by an NMS. The state information maintained by any NMS is an abstraction, or an approximation of reality, sufficient to control the system being managed. However, as NMS implementations develop, with complex correlation and closed-loop control systems increasingly being deployed, and as they become more decentralised, allowing more device state information to be monitored efficiently, the amount of data required to describe the NMS's view of the network state will grow considerably.
When a network failure of some form occurs (the exact nature of the failure being unimportant), by the time the failure has been identified, the system state may have changed from that which existed at the time of the failure. Indeed the visible symptoms will often have been caused by an underlying problem that occurred even earlier. If the system state, or at least the NMS's abstraction of this state, could be examined at any point in the past then this would help in a “root-cause analysis”. The difficulty in satisfying this requirement, at least in the general case, is one of the reasons that makes root cause analysis so challenging a problem.
Various tools have been developed to help store the current state of a system. A good example is a Java Data Object (JDO). Here, a set of Java classes is defined to represent the state of the system being modelled. All the application logic then just worries about manipulating and traversing instances of these classes, without concerning itself with precisely how this data is stored in the database, retrieved from it etc. The implementer then writes a bunch of auxiliary files that describe, declaratively, how these classes should map to the database. For example, the declarative specifications in these files might state that one field should be transient, i.e. not stored in the database, another should be stored using a particular representation, another in a specific column of a specific table, and so on. A JDO enhancer takes these declarative specifications, along with the compiled version of the original code (which “knows” nothing about databases) and produces an altered version of the code that can now interact with a database. So, for example, in the original code there may be code that changes the value of a field in an instance of a class, whereas in the altered version of the (compiled) code the system will take care of ensuring this change is made persistently, in the database, by emitting the necessary Structured Query Language (SQL) statements to update the appropriate rows in the required tables. The code generated by a JDO enhancer does a lot more than this, e.g. caching instances of objects, automatically creating instances of objects in memory, from data in the database, as the user traverses links between objects, and so on. However, the important thing to note is that the user can largely ignore all this when writing the application, relying on the JDO enhancer to add in all the tedious stuff afterwards. Furthermore, because the enhancer is driven by a declarative specification of what is required, it is relatively easy to make changes, e.g. to add additional fields, change the mapping to a different database schema etc.
However, maintaining historical state is a lot harder than maintaining just the current state of the system for a variety of reasons, e.g.                We quickly run out of disk space, so we need to define how much of the past state we really need to maintain.        We now have to introduce the concept of time, i.e. we might want to traverse our abstraction of the network topology (in a network management scenario) as it existed at time t, where t is earlier than the current time. The database tables must all get a lot more complicated to support time, and queries that are time-specific also get very complex very quickly.        
Manually writing code to maintain this historical state is much harder than writing the code required to simply represent the current state of the system. Furthermore, there are, at present, no tools to help in this task.
Therefore, it is an object of the present invention to provide a method and system for management of historical data, especially, although not exclusively for, management of historical state information for a telecommunications network.